<html>
<head><meta charset="utf-8"><title>Improving TrustedRandomAccess and its Zip specialization · t-libs · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/index.html">t-libs</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html">Improving TrustedRandomAccess and its Zip specialization</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="227088066"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227088066" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227088066">(Feb 20 2021 at 12:18)</a>:</h4>
<p>TrustedRandomAccess (TRA) has proven itself useful in several places for specialization but the <code>iter::Zip</code> specialization has been repeat source of unsoundness</p>
<ul>
<li><a href="https://github.com/rust-lang/rust/issues/81740">https://github.com/rust-lang/rust/issues/81740</a></li>
<li><a href="https://github.com/rust-lang/rust/issues/82291">https://github.com/rust-lang/rust/issues/82291</a></li>
<li><a href="https://github.com/rust-lang/rust/issues/82282">https://github.com/rust-lang/rust/issues/82282</a></li>
<li><a href="https://github.com/rust-lang/rust/pull/80670">https://github.com/rust-lang/rust/pull/80670</a></li>
<li>more?</li>
</ul>
<p>I think this is because TRA is quite non-local. It doesn't update the state of the iterator source or adapters which means use-sites of TRA must manage the state correctly. But iterator adapters can be composed, which means there are potentially several nested use-sites which <em>together</em> need to keep the state correctly. And there can be several different methods that need to work together, e.g. <code>next()</code>, <code>next_back()</code>, a wrapper implementation of <code>__iterator_get_unchecked</code>, the internal iteration methods, <code>Drop</code> implementations and potentially others.</p>
<p>Additionally the lack of state update means that TRA can't be implemented on owning iterators for <code>T: Drop</code> types, which leaves some optimization potential on the table.</p>
<p><code>ZipImpl</code> is the worst offender here since it implements everything and tries to coordinate multiple iterators on top of that. <a href="https://github.com/rust-lang/rust/blob/5c9c5bd5807bef81f9989728d00a6985f4375e55/library/alloc/src/vec/source_iter_marker.rs#L131-L142">Other uses of TRA</a> can be fairly benign in comparison.</p>
<p>So what can be done?</p>
<ul>
<li>Keep fixing bugs. Add more tests. Add comments why it's a minefield and what needs to be considered. Are there some invariants we could check with debug asserts?</li>
<li>Revisit motivating benchmarks and see if removing TRA would be tolerable. The optimizer might be better than it was in the past.</li>
<li>Optimize iterator sources (<span class="user-mention" data-user-id="301846">@Sebastian Dröge</span>  suggests in <a href="https://github.com/rust-lang/rust/issues/75935#issuecomment-680789942">this comment</a> that current implementations are not very llvm-friendly) and adapters so we don't need TRA anymore to get fast <code>zip()</code>. Together with collecting optimizer shortfalls that need to be fixed. This seems to be hard since various adapters can introduce multiple loop exits which afaik hinder a lot of optimizations, especially on Zip where multiple iterator pipelines have to work in lockstep.</li>
<li>Replace TRA with a more limited trait that is less non-local. What I had in mind is adding a cleanup method that informs the pipeline at the end of iteration how many front and back elements have been consumed so that the pipeline can bring itself back into a consistent state. It would be the responsibility of the <code>__iterator_get_unchecked</code> caller to invoke it after it's done iterating or on panic. This would be mostly useful for <code>fold</code> and other internal iteration methods. But that would mean we would lose optimizations on <code>for</code> loops, on the other hand it would simplify things a great deal because fewer methods have to work correctly together and state management would immediately return to the right place after iteration, so the iterator would only temporarily be inconsistent at a single callsite. And it would also enable TRA implementations for iterators implementing <code>Drop</code>.</li>
<li>... ideas?</li>
</ul>
<p>CC <span class="user-mention" data-user-id="338379">@Giacomo Stevanato</span></p>



<a name="227096202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227096202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227096202">(Feb 20 2021 at 14:57)</a>:</h4>
<blockquote>
<p>I think this is because TRA is quite non-local. It doesn't update the state of the iterator source or adapters which means use-sites of TRA must manage the state correctly.</p>
</blockquote>
<p>I think this is a prerequisite of these optimizations because they're enabled by the fact that the source iterator doesn't check its state. </p>
<p>In the github issue I was thinking we could make it so that the source iterator can update its state (if this is cheap enough) without checking if it is valid (which is what mostly hinders LLVM optimizations). This will allow to implement TRA for <code>vec::IntoIter</code> and stuff like that, it won't solve the underlying safety hazards.</p>
<blockquote>
<p>But iterator adapters can be composed, which means there are potentially several nested use-sites which together need to keep the state correctly.</p>
</blockquote>
<p>I don't quite agree with this. Each iterator adapter should be sound by itself, provided the caller respect the TRA contract, but that's a common contract any adapter should respect. If an adapter breaks that contract (like <code>Zip</code> did) then it's a problem in that adapter, not in the composing them.</p>
<blockquote>
<p>and there can be several different methods that need to work together, e.g. <code>next()</code>, <code>next_back()</code>, a wrapper implementation of <code>__iterator_get_unchecked</code>, the internal iteration methods, <code>Drop</code> implementations and potentially others.</p>
</blockquote>
<p>On top of this we're also trying to keep side effects in order to not expose implementation details. This was the cause of <a href="https://github.com/rust-lang/rust/issues/81740">#81740</a>, <a href="https://github.com/rust-lang/rust/issues/82291">#82291</a> and <a href="https://github.com/rust-lang/rust/issues/82282">#82282</a>.  And we're failing to keep them (see <a href="https://github.com/rust-lang/rust/issues/82303">#82303</a> for example). </p>
<p>IMO without preserving side-effects TRA would become much simplier,  but this would come at the cost of exposing implementation details that some code could rely upon. However from my experience the side effects are the unexpected and confusing thing, and any codebase should avoid to rely on them.</p>
<blockquote>
<p>Keep fixing bugs. Add more tests. Add comments why it's a minefield and what needs to be considered. Are there some invariants we could check with debug asserts?</p>
</blockquote>
<p>As I already said <a href="https://github.com/rust-lang/rust/pull/82289#discussion_r579141033">here</a> I was planning to document the safety of the specialized <code>ZipImpl</code>. This might work out well, or just expose even more unfixable bugs, who knows.</p>
<blockquote>
<p>Revisit motivating benchmarks and see if removing TRA would be tolerable. The optimizer might be better than it was in the past.</p>
</blockquote>
<p>Might as well give it a try, but I wouldn't expect much from it.</p>
<blockquote>
<p>Optimize iterator sources (@Sebastian Dröge suggests in this comment that current implementations are not very llvm-friendly) and adapters so we don't need TRA anymore to get fast zip(). Together with collecting optimizer shortfalls that need to be fixed. This seems to be hard since various adapters can introduce multiple loop exits which afaik hinder a lot of optimizations, especially on Zip where multiple iterator pipelines have to work in lockstep.</p>
</blockquote>
<p>I don't think this will solve the problem. <a href="https://godbolt.org/z/x4bEbq">Here</a>'s a microbenchmark that uses the alternative proposed <a href="https://github.com/rust-lang/rust/issues/75935#issuecomment-680807329">here</a>, unfortunately it doesn't even vectorize. I think it would be better to wait for the LLVM "bug" to be fixed, hoping it will translate well when we add adapters.</p>
<blockquote>
<p>Replace TRA with a more limited trait that is less non-local. What I had in mind is adding a cleanup method that informs the pipeline at the end of iteration how many front and back elements have been consumed so that the pipeline can bring itself back into a consistent state. It would be the responsibility of the __iterator_get_unchecked caller to invoke it after it's done iterating or on panic. This would be mostly useful for fold and other internal iteration methods. But that would mean we would lose optimizations on for loops, on the other hand it would simplify things a great deal because fewer methods have to work correctly together and state management would immediately return to the right place after iteration, so the iterator would only temporarily be inconsistent at a single callsite. And it would also enable TRA implementations for iterators implementing Drop.</p>
</blockquote>
<p>This is an interesting idea we could explore. It should reduce the complexity deriving from modifying the same state from different methods, however I'm worried it will have the same problems the current implementation has when we will try to preserv side-effects</p>



<a name="227110813"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227110813" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227110813">(Feb 20 2021 at 19:03)</a>:</h4>
<blockquote>
<p>In the github issue I was thinking we could make it so that the source iterator can update its state (if this is cheap enough) without checking if it is valid (which is what mostly hinders LLVM optimizations). This will allow to implement TRA for vec::IntoIter and stuff like that,</p>
</blockquote>
<p>Don't think that'll work since to allow indexed access the base from which we index can't change.</p>
<blockquote>
<p>I think this is a prerequisite of these optimizations because they're enabled by the fact that the source iterator doesn't check its state. </p>
</blockquote>
<p>More or less, yeah, during iteration. That's why I proposed the more restricted version that does a fixup after iteration.</p>
<blockquote>
<p>I don't quite agree with this. Each iterator adapter should be sound by itself, provided the caller respect the TRA contract, but that's a common contract any adapter should respect. </p>
</blockquote>
<p>Well yeah, of course each has to uphold the contract. But Zip is stateful, so you can first manipulate the inner Zip's state and then wrap it into another adapter which uses TRA too. That increases the number of possible cases to consider. I.e. <code>Zip:: __iterator_get_unchecked</code> doesn't just have to work on its own but also in conjunction with all the other methods.</p>
<blockquote>
<p>On top of this we're also trying to keep side effects in order to not expose implementation details. This was the cause of <a href="https://github.com/rust-lang/rust/issues/81740">#81740</a>, <a href="https://github.com/rust-lang/rust/issues/82291">#82291</a> and <a href="https://github.com/rust-lang/rust/issues/82282">#82282</a>. And we're failing to keep them (see <a href="https://github.com/rust-lang/rust/issues/82303">#82303</a> for example). </p>
</blockquote>
<p>Hrm yeah, good point. That causes a lot of complexity. It would be great if we could just get rid of that and just say it's not part of the API contract.</p>
<blockquote>
<p>however I'm worried it will have the same problems the current implementation has when we will try to preserv side-effects</p>
</blockquote>
<p>It would only have to implement internal iteration methods and <code>__iterator_get_unchecked</code>. Which means <code>next()</code> and <code>next_back()</code> could use the default implementations, greatly reducing the complexity.</p>



<a name="227113623"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227113623" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227113623">(Feb 20 2021 at 19:52)</a>:</h4>
<blockquote>
<p>It would be great if we could just get rid of that and just say it's not part of the API contract.</p>
</blockquote>
<p>Unfortunately <code>Iterator::zip</code>'s  docs guarantee the short circuit behaviour :(</p>
<blockquote>
<p>It would only have to implement internal iteration methods and __iterator_get_unchecked. Which means next() and next_back() could use the default implementations, greatly reducing the complexity.</p>
</blockquote>
<p>Yeah, that part of the complexity would be gone, but you still need the logic to "fix" the source iterator and to preserve side-effects</p>



<a name="227113721"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227113721" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227113721">(Feb 20 2021 at 19:54)</a>:</h4>
<blockquote>
<p>Unfortunately Iterator::zip's docs guarantee the short circuit behaviour :(</p>
</blockquote>
<p>Short circuiting means that it terminates early, not that the remainder gets consumed.</p>



<a name="227113810"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227113810" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227113810">(Feb 20 2021 at 19:55)</a>:</h4>
<blockquote>
<p>but you still need the logic to "fix" the source iterator and to preserve side-effects</p>
</blockquote>
<p>Yeah, the fixing could indeed take some effort. But the side-effect preserving could possibly piggy-back on default implementations by calling them after the fold is done and the fixup has happened.</p>



<a name="227114271"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227114271" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227114271">(Feb 20 2021 at 20:03)</a>:</h4>
<blockquote>
<p>Short circuiting means that it terminates early, not that the remainder gets consumed.</p>
</blockquote>
<p>But from how it's phrased it's kind of implied that <code>next</code> will be called on the first source iterator</p>



<a name="227114323"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227114323" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227114323">(Feb 20 2021 at 20:03)</a>:</h4>
<blockquote>
<p>Yeah, the fixing could indeed take some effort. But the side-effect preserving could possibly piggy-back on default implementations by calling them after the fold is done and the fixup has happened.</p>
</blockquote>
<p>Right, that would probably make it easier to implement</p>



<a name="227114738"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/227114738" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#227114738">(Feb 20 2021 at 20:09)</a>:</h4>
<p>Well, all implementations of TRA are also ExactSizeIterator, so arguably it would be ok for zip to first inspect the length and bail out early if it's 0.</p>



<a name="228057826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228057826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228057826">(Feb 27 2021 at 13:15)</a>:</h4>
<blockquote>
<p>... ideas?</p>
</blockquote>
<p>Another ingredient here could be to more systematically test iterators in Miri. Testing iterators properly is hard, so it would be really valuable to have a function like <code>fn test_iterator&lt;T: Iterator&gt;(t: T)</code> (or so) that collects all the best practices of what it takes to test an iterator. When running this in Miri it would detect if any kind of UB arises in that test. When I did that with <a href="https://github.com/rust-lang/miri/blob/74b771423a7d78e3ca000c14c1e153fbcea488e1/tests/run-pass/vec.rs#L4">this simple function</a>, I already found illegal aliasing in several stdlib iterators.</p>
<p>Testing can certainly not replace refactorings that make bugs less likely, but I feel like there's still a lot of room for improvement in properly testing iterators.</p>



<a name="228058087"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228058087" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Steven Fackler <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228058087">(Feb 27 2021 at 13:20)</a>:</h4>
<p>Even outside of soundness issues a standard test harness function like that would be great to verify other requirements like preservation of side effects</p>



<a name="228058257"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228058257" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228058257">(Feb 27 2021 at 13:24)</a>:</h4>
<p>It would also be really useful for non-stdlib iterators I imagine</p>



<a name="228079339"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228079339" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228079339">(Feb 27 2021 at 19:59)</a>:</h4>
<p>That's probably not a bad idea in general but wouldn't have helped with some of the Zip issues which rely on first partially consuming an iterator and then wrapping it in an adapter and doing something with that. Zip + TRA is special in several ways. I mean TRA was originally written for just that, although we're finding uses for it in other places.</p>
<blockquote>
<p>that would be great to verify other requirements like preservation of side effects</p>
</blockquote>
<p>I'm not even sold on the whole preserving side-effects thing. Java iterators don't promise that for one and there are entirely safe ways one can implement adapters that will skip side-effects while upholding the rest of the API.</p>



<a name="228081307"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228081307" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228081307">(Feb 27 2021 at 20:32)</a>:</h4>
<p>But yeah, writing tests that specifically target specializations instead of the general case and then running them under miri would be good.</p>



<a name="228081572"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228081572" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228081572">(Feb 27 2021 at 20:36)</a>:</h4>
<p>Have there ever been any discussions about changing the for loop desugaring to use try_fold?</p>



<a name="228083877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228083877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228083877">(Feb 27 2021 at 21:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="330154">The 8472</span> <a href="#narrow/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization/near/228081572">said</a>:</p>
<blockquote>
<p>Have there ever been any discussions about changing the for loop desugaring to use try_fold?</p>
</blockquote>
<p>wouldn't that make it tricky at best to translate <code>?</code> or <code>return</code> inside the loop?</p>



<a name="228084158"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228084158" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228084158">(Feb 27 2021 at 21:26)</a>:</h4>
<p>Ah, yeah. I only considered break and continue which could be mapped to <code>ControlFlow</code>. Maybe one could conditionally desugar based on their presence but that seems too hacky. Too bad. try_fold &amp; co make some optimizations a lot easier.</p>



<a name="228084171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228084171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228084171">(Feb 27 2021 at 21:27)</a>:</h4>
<p><span class="user-mention silent" data-user-id="330154">The 8472</span> <a href="#narrow/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization/near/228081572">said</a>:</p>
<blockquote>
<p>Have there ever been any discussions about changing the for loop desugaring to use try_fold?</p>
</blockquote>
<p>Niko brought that up in <a href="https://github.com/rust-lang/rfcs/pull/3058???#pullrequestreview-592106494">https://github.com/rust-lang/rfcs/pull/3058???#pullrequestreview-592106494</a>, but in general not having TCP closures makes that challenging.</p>



<a name="228086514"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/228086514" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#228086514">(Feb 27 2021 at 22:15)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization/near/228083877">said</a>:</p>
<blockquote>
<p>wouldn't that make it tricky at best to translate <code>?</code> or <code>return</code> inside the loop?</p>
</blockquote>
<p>Since <code>?</code> desugars to a <code>return</code> you could express both of them with an additional variant in the "err" path.  It makes the desugar a bit trickier, but it isn't out of question. <code>break</code>/<code>continue</code> from outer scopes however are much more problematic because they would require a custom enum for each <code>for</code> loop</p>



<a name="232862478"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232862478" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232862478">(Apr 02 2021 at 05:30)</a>:</h4>
<p><span class="user-group-mention" data-user-group-id="2645">@T-libs</span> what would it take to get rid of the <em>zip specialization preserves side-effects of iterator A even if B is exhausted</em> guarantee?</p>
<p>Specifically the second sentence <a href="https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.zip">in the documentation</a> (emphasis mine):</p>
<blockquote>
<p>If either iterator returns None, next from the zipped iterator will return None. <em>If the first iterator returns None, zip will short-circuit and next will not be called on the second iterator.</em></p>
</blockquote>
<p>It would be a breaking change. Would a PR + FCP be sufficient? Crater run?</p>
<p>Some arguments in favor of removing it:</p>
<ul>
<li>the guarantee already isn't upheld in some cases and it doesn't appear to have broken anyone (<a href="https://github.com/rust-lang/rust/issues/82303">#82303</a>)</li>
<li>on top of that additional specializations have been introduced that break it further (my fault, I just realized!)</li>
<li>quite some fragile code exists only to uphold it and serves no other purpose</li>
<li>the current language mostly describes an implementation detail that could have been done differently when it was first implemented and focuses on <code>next()</code> which doesn't account for all the shiny new internal iteration methods that have been added over time.</li>
<li>it makes TrustedRandomAccess easier to use for things unrelated to Zip</li>
</ul>



<a name="232867574"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232867574" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232867574">(Apr 02 2021 at 06:55)</a>:</h4>
<p>CC <span class="user-mention" data-user-id="139363">@bluss</span> who originally implemented the explicit side-effect preservation.</p>



<a name="232878636"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232878636" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mara <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232878636">(Apr 02 2021 at 09:21)</a>:</h4>
<p><span class="user-mention" data-user-id="330154">@The 8472</span> i think that's fine. the code there to keep that guarantee is extremely fragile and hard to maintain. reviewing pull requests there is always a challenge, so i'm all for simplifying things. i suppose we could do a crater run, but i think just a quick FCP would be enough.</p>



<a name="232921568"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232921568" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232921568">(Apr 02 2021 at 16:45)</a>:</h4>
<p>Ugh, removing the side-effects handling on <code>next()</code>impacts <code>next_back()</code> behavior too. I could remove the side-effects <em>there</em>,  but that would be more radical since it could skip into the middle of an iterator rather than just omitting things around the edges. And I don't think we have a precedent for that kind of iterator behavior. I think removing the guarantee in the documentation still makes sense since we're not always delivering it anyway but removing the logic will be trickier.</p>
<p>The java Stream API handled this kind of specification work way better. They explicitly note that many of the methods must be stateless and any side-effects in them will not be preserved by optimizations.</p>



<a name="232935679"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232935679" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232935679">(Apr 02 2021 at 18:35)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/83791">#83791</a> PR for the documentation change.</p>



<a name="232963362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/232963362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#232963362">(Apr 02 2021 at 23:21)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/83796">#83796</a> PR could be used for a crater run. It's not necessarily what I want to get merged, it's does more than necessary to have a better chance at finding breakage.</p>



<a name="238963469"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238963469" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238963469">(May 16 2021 at 09:30)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/issues/85342">#85342</a> proposes <code>zip_exact</code> which would require/check that iterators are of the same length. Perhaps it would be less dicy to just remove all the specializations from <code>zip</code>, implement <code>zip_exact</code> and add simpler specializations on that which could bail out early if lengths don't match. That would simplify things without risking backwards compatibility or surprising behavior.</p>



<a name="238965826"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238965826" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238965826">(May 16 2021 at 10:10)</a>:</h4>
<p>I think having a separate adapter might be a good idea, however that proposal doesn't cover cases where you don't have an ExactSizeIterator but also don't care about side effects</p>



<a name="238965863"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238965863" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238965863">(May 16 2021 at 10:11)</a>:</h4>
<p>Think for example of zipping with an infinite iterator</p>



<a name="238966040"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238966040" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238966040">(May 16 2021 at 10:14)</a>:</h4>
<p>I mentioned that :D that can be solved with a <code>take(other.len())</code></p>



<a name="238966103"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238966103" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238966103">(May 16 2021 at 10:15)</a>:</h4>
<p><code>impl DoubleEndedIterator for Zip</code>  requires ExactSizeIterator anyway. And specializations require <code>TrustedRandomAccess</code> which implies known length.</p>



<a name="238966230"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238966230" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238966230">(May 16 2021 at 10:16)</a>:</h4>
<p>There are other hypothetical optimizations in iterator chains where one could want to skip side-effects without knowing lengths, but they're on other adapters, not zip.</p>



<a name="238966871"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238966871" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238966871">(May 16 2021 at 10:28)</a>:</h4>
<p>The default implementation could panic lazily when it encounters a size mismatch, so it can support !ExactSizeIterator. The double-ended or specialized ones could panic early.</p>



<a name="238966960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238966960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238966960">(May 16 2021 at 10:30)</a>:</h4>
<p><code>Take</code> implements <code>ExactSizeIterator</code> only if the inner iterator does, but <code>Repeat</code> don't implement it (it implements <code>TrustedLen</code> though</p>



<a name="238967011"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/238967011" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#238967011">(May 16 2021 at 10:31)</a>:</h4>
<p>It would still ensure that the sizes match.</p>



<a name="242301533"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242301533" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242301533">(Jun 11 2021 at 05:02)</a>:</h4>
<p>I <em>think</em> this thread is most relevant to issues <a href="https://github.com/rust-lang/rust/issues/85863">#85863</a> <a href="https://github.com/rust-lang/rust/issues/85873">#85873</a> <a href="https://github.com/rust-lang/rust/issues/82303">#82303</a> <a href="https://github.com/rust-lang/rust/issues/85969">#85969</a></p>



<a name="242301538"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242301538" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242301538">(Jun 11 2021 at 05:02)</a>:</h4>
<p>I’m trying to get my head around the scope of the potential unsoundness here</p>



<a name="242301574"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242301574" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242301574">(Jun 11 2021 at 05:04)</a>:</h4>
<p>because  the T-compiler team is talking about doing an emergency backport, in time for the 1.53 release, of the parts of PRs <a href="https://github.com/rust-lang/rust/issues/85874">#85874</a> and <a href="https://github.com/rust-lang/rust/issues/85975">#85975</a> that are “just” removing optimizations that we fear may be unsound</p>



<a name="242301631"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242301631" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242301631">(Jun 11 2021 at 05:04)</a>:</h4>
<p>(if there’s a better thread, please do point me to it…)</p>



<a name="242301770"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242301770" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242301770">(Jun 11 2021 at 05:07)</a>:</h4>
<p><span class="user-mention" data-user-id="330154">@The 8472</span> ^ ?</p>



<a name="242304572"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242304572" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242304572">(Jun 11 2021 at 06:06)</a>:</h4>
<p>actually <span class="user-mention" data-user-id="280891">@Frank Steffahn</span> added a <a href="#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202021-06-10.20.2354818/near/242225674">good summary</a> after the meeting was over yesterday.</p>



<a name="242304631"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242304631" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242304631">(Jun 11 2021 at 06:06)</a>:</h4>
<p>in any case, T-compiler will be meeting on Friday at <time datetime="2021-06-11T14:00:00Z">2021-06-11T10:00:00-04:00</time>  to discuss</p>



<a name="242304637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242304637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242304637">(Jun 11 2021 at 06:06)</a>:</h4>
<p>in <a class="stream-topic" data-stream-id="238009" href="/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Badhoc.5D.202021-06-11.20unsound.20stdlib.20specialization.20and.201.2E53">#t-compiler/meetings &gt; [adhoc] 2021-06-11 unsound stdlib specialization and 1.53</a></p>



<a name="242310436"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242310436" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242310436">(Jun 11 2021 at 07:38)</a>:</h4>
<p><span class="user-mention" data-user-id="116083">@pnkfelix</span>  <a href="https://github.com/rust-lang/rust/issues/85975">#85975</a> isn't about unsoundness, "only" a regression in observable behavior stemming from the interaction of zip, trusted random access and backwards iteration. <a href="https://github.com/rust-lang/rust/issues/82303">#82303</a> is also about observable behavior. The cases could be mooted by declaring that iterators may elide some side-effects of some adapters, but the libs team doesn't seem in favor of that, at least in the general case. The latter could also be solved by introducing a new Zip implementation (ZipExact) that has some tighter requirements which can't encounter that case.</p>
<p><a href="https://github.com/rust-lang/rust/issues/85874">#85874</a> and <a href="https://github.com/rust-lang/rust/issues/85863">#85863</a> indeed are about unsoundness, albeit in fairly rare cases where someone first advances an iterator involving zip and then coerces it to a type with a different lifetime, basically the very thing that min_specialization should have avoided but still left a hole via <code>rustc_unsafe_specialization_marker</code>.</p>



<a name="242314031"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242314031" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Frank Steffahn <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242314031">(Jun 11 2021 at 08:19)</a>:</h4>
<p>One difference between <a href="https://github.com/rust-lang/rust/issues/82303">#82303</a> and <a href="https://github.com/rust-lang/rust/issues/85969">#85969</a> is that <a href="https://github.com/rust-lang/rust/issues/85969">#85969</a> is a regression from stable to beta 1.53, while the other one is older.</p>



<a name="242336591"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/242336591" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#242336591">(Jun 11 2021 at 12:19)</a>:</h4>
<p>Okay. I think I have both your points summarized in my prep notes for the mtg, but I’ll need to check when I’m not on mobile device</p>



<a name="243211138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/243211138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#243211138">(Jun 18 2021 at 21:45)</a>:</h4>
<p>Another one. <a href="https://github.com/rust-lang/rust/issues/86443">#86443</a></p>



<a name="243218415"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/243218415" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> The 8472 <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#243218415">(Jun 19 2021 at 00:19)</a>:</h4>
<p>Oh, and of course it's due to the logic trying to preserve side-effects <em>cough cough</em></p>



<a name="243234877"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/219381-t-libs/topic/Improving%20TrustedRandomAccess%20and%20its%20Zip%20specialization/near/243234877" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Giacomo Stevanato <a href="https://rust-lang.github.io/zulip_archive/stream/219381-t-libs/topic/Improving.20TrustedRandomAccess.20and.20its.20Zip.20specialization.html#243234877">(Jun 19 2021 at 07:26)</a>:</h4>
<p>Actually, that comes from the fix of another bug also caused by logic trying to preserve side-effects<br>
<a href="https://github.com/rust-lang/rust/pull/82292/files#diff-bcb1cbec2f56e2f74fdc31ad2c1637675a7daa9a21edaeb129f10eed8936b83b">https://github.com/rust-lang/rust/pull/82292/files#diff-bcb1cbec2f56e2f74fdc31ad2c1637675a7daa9a21edaeb129f10eed8936b83b</a><br>
Blame this one on me</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>